The fence description uses the phrase "a matching pair of hyphens",
which can be misread as describing exactly two individual hyphens.
The constraints on fence length and matching are also compressed into
a single sentence with a trailing subclause ("from 3 to 255") that
reads as nonrestrictive.

Let's give each constraint its own sentence: what a fence is, where
it must appear, the length bounds on the opening fence, the matching
requirement for the closing fence, and trailing whitespace.  This
makes the structure clearer.

The infostring sentence uses an inverted construction ("Following the
opening fence may be an infostring"); it's a bit awkward.

Let's use active voice and tighten the phrasing.

The body restriction sentence combines two unrelated constraints --
the hyphen-line restriction and the carriage-return ban -- in a single
sentence joined by "or".  This makes "or carriage returns" read as
parallel to "hyphens", as though the line could maybe start with
carriage returns.

Let's split these into two separate sentences so that each constraint
stands on its own.

The prose mentions "horizontal whitespace" in two places (fence
trailing content and infostring trailing content) without linking
to the grammar definition.  Since `HORIZONTAL_WHITESPACE` is now a
defined production in Whitespace, let's add a link so readers can
click through to the precise definition.

The frontmatter removal section in `input-format.md` is a
single sentence ("After some whitespace, frontmatter may next
appear in the input") that doesn't clearly describe the removal
behavior.  By contrast, the shebang removal section provides a full
description with an example.

Let's rewrite the section with a precise description of the removal
process and add an annotated example.

The `frontmatter.document` rule said "Frontmatter may only be preceded
by a shebang and whitespace", where the "and" could be misread as
requiring both a shebang and whitespace rather than listing the set of
things allowed to precede frontmatter.

Since we merged the shebang prose revision (#2192),
the shebang position rule now reads as a positive statement of where
the shebang may appear.  Let's follow the same pattern here: state
positively where frontmatter may appear rather than leaning on "only"
and a negative constraint.

We'll also rename the rule identifier to `frontmatter.position` in
keeping with our conventions.

The example under `frontmatter.intro` used an external crate, a
nontrivial script body, and a bare `rust` code block that would
fail CI since the test runner doesn't support frontmatter.  Let's
simplify it to mirror the example in the frontmatter removal section
of `input-format.md`, and let's wrap it in an `EXAMPLE` admonition
consistent with our convention for examples that aren't demonstrating
the behavior of a specific rule.

The intro under `frontmatter.intro` said "an optional section for
content intended for external tools without requiring these tools
to have full knowledge of the Rust grammar."  This was a negative
construction (what frontmatter doesn't require) rather than a positive
one (what it is and what it enables).

In this commit, we rewrite the intro as "an optional section of
metadata whose syntax allows external tools to read it without parsing
Rust."  This tells the reader three things in one sentence: what
frontmatter is, who it's for, and the key design property.

For the `WHITESPACE` grammar rule, we cite `Pattern_White_Space`.  For
`HORIZONTAL_WHITESPACE`, we hadn't cited provenance.  Let's do that.

Horizontal whitespace, in a Unicode context, is defined by UAX
31, Section 4.1, which categorizes `Pattern_White_Space` into
line endings, ignorable format controls, and horizontal space.
The horizontal space category is exactly the two characters our
grammar specifies.